Міністерство освіти і науки України
Національний університет "Львівська політехніка"
EMBED Word.Picture.6
“Логічне проектування бази даних”
Методичні вказівки до лабораторного заняття з дисципліни
“Бази даних в інформаційно-комп'ютерних технологіях”
для студентів базового напрямку 6.091 “Електронні апарати”
Затверджено на засіданні кафедри ЕЗІКТ
Протокол № ___ від ___ ______ 2006 р.
Львів 2005
Логічне проектування бази даних. Методичні вказівки до лабораторного заняття з дисципліни "Бази даних в інформаційно-комп'ютерних технологіях” для студентів базового напрямку 6.091 “Електронні апарати”/ Укл. Л.К.Гліненко.-Львів; Вид-во Нац. ун-ту "Львівська політехика" , 2006. - 28 с.
Укладач: Л.К.Гліненко, канд. техн. наук, доц.
Відповідальний за випуск – Г.В.Юрчик , канд. техн. наук, доц.
Рецензенти: О.М.Воблий, канд. техн. наук, доц.
І.В.Атаманова, канд. техн. наук, доц.
ЛОГІЧНЕ ПРОЕКТУВАННЯ БАЗИ ДАНИХ
1. Мета роботи
Вивчення задач та основних кроків і практичне виконання етапу логічного проектування бази даних та створення логічної моделі спроектованої логічної бази даних засобами Microsoft Visio у відповідності з вимогами наявної СУБД
2. Теоретичні відомості
2.1. Логічне проектування баз даних
Мета логічного етапу проектування - організація даних, виділених на етапі інфологічного проектування у форму, прийняту в обраній СУБД Слід зазначити, що деякі CASE-засоби, зокрема, програмний продукт ErWin та PowerBuilder, застосовують дещо іншу термінологію стосовно різновидів моделей БД та етапів проектування. Зокрема, використовується поняття побудови моделі на логічному і на фізичному рівні, причому при моделюванні на логічному рівні дані представляються так, як виглядають у реальному світі, і можуть називатися так, як вони називаються в реальному світі, наприклад "Постійний клієнт", "Відділ" чи "Прізвище співробітника". Об'єкти моделі, що представляються на логічному рівні, називаються сутностями й атрибутами. Логічна модель даних може бути побудована на основі іншої логічної моделі, наприклад на основі моделі процесів. Логічна модель даних у ErWin є універсальної і ніяк не зв'язана з конкретною реалізацією СУБД, а залежить лише від типу обраної СУБД.
Фізична модель даних, навпроти, залежить від конкретної СУБД, фактично будучи відображенням системного каталогу. У фізичній моделі міститься інформація про всі об'єкти БД. Оскільки стандартів на об'єкти БД не існує (наприклад, немає стандарту на типи даних), фізична модель залежить від конкретної реалізації СУБД. Отже, однієї і тієї ж логічної моделі можуть відповідати кілька різних фізичних моделей. Якщо в логічній моделі не має значення, який конкретно тип даних має атрибут, то у фізичній моделі важливо описати всю інформацію про конкретні фізичні об'єкти - таблицях, колонках, індексах, процедурах і т.д. Поділ моделі даних на логічні і фізичні дозволяє вирішити кілька важливих задач.
. Задачею логічного етапу проектування є відображення об'єктів предметної області в об'єкти використовуваної моделі даних, щоб це відображення не суперечило семантиці предметної області і було по можливості найкращим (ефективним, зручним і т.д.). З погляду обраної СУБД задача логічного проектування реляційної бази даних складається в обґрунтованому прийнятті рішень про те:
з яких відношень (таблиць) повинна складатися база даних;
які атрибути повинні бути в цих відношень;
як забезпечити виконання вимог до реляційної БД;
як позбутися суперечливості та надлишковості даних;
які обмеження повинні бути накладені на атрибути і відносини бази даних, щоб забезпечити її цілісність.
2.2. Рівні логічної моделі реляційної БД
Розрізняють три рівні логічної моделі для БД реляційного типу, що відрізняються по глибині представлення інформації про дані:
діаграма сутність-зв'язок (Entity Relationship Diagram, ERD);
модель даних, заснований на ключах (Key Based model, KB);
повна атрибутивна модель (Fully Attributed model, FA).
Діаграма сутність-зв'язок я...
